CSS Logical Properties Level 2: Building a Truly Global Web with Enhanced Writing Mode Support

For decades, web developers have built layouts using a vocabulary rooted in the physical world: top, bottom, left, and right. We set a margin-left, a padding-top, and a border-right. This mental model served us well when the web was predominantly a left-to-right, top-to-bottom medium. However, the web is global. It's a platform for all languages and cultures, many of which don't follow this simple directional flow.

Languages like Arabic and Hebrew are written right-to-left. Traditional Japanese and Chinese can be written vertically, from top-to-bottom and right-to-left. Forcing a physical, left-to-right CSS model onto these writing systems results in broken layouts, a frustrating user experience, and a mountain of code overrides. This is where CSS Logical Properties and Values come in, representing a fundamental paradigm shift from physical directions to flow-relative, logical directions. While Level 1 laid the groundwork, CSS Logical Properties Level 2 completes the picture, providing the tools we need to build truly universal, writing-mode-aware user interfaces.

This comprehensive guide will take you on a deep dive into the enhancements brought by Level 2. We will start with a refresher of the core concepts, then explore the new properties and values that fill the gaps, and finally, put it all into practice by building a component that adapts seamlessly to any writing mode. Prepare to change the way you think about CSS layout forever.

A Quick Refresher: The Core Concepts of Logical Properties (Level 1)

Before we can appreciate the additions in Level 2, we must have a solid understanding of the foundation laid by Level 1. The entire system is built on two key concepts: the writing mode and the resulting block and inline axes.

The Four Writing Modes

The writing-mode CSS property determines the direction text is laid out. While we often take the default for granted, there are several values that fundamentally change how content flows on the page:

• horizontal-tb: This is the default for most Western languages. Text flows horizontally (inline axis) from left-to-right (or right-to-left based on direction), and lines stack from top-to-bottom (block axis).
• vertical-rl: Used for traditional East Asian typography (e.g., Japanese, Chinese). Text flows vertically from top-to-bottom (inline axis), and lines stack from right-to-left (block axis).
• vertical-lr: Similar to the above, but lines stack from left-to-right (block axis). Less common, but used in some contexts like Mongolian script.
• sidelong-rl / sidelong-lr: These are for specific use cases where you want to lay glyphs on their side. They are less common in general web content.

The Crucial Concept: Block vs. Inline Axis

This is the most important concept to grasp. In a logical world, we stop thinking about "vertical" and "horizontal" and start thinking in terms of the block and inline axes. Their orientation depends entirely on the writing-mode.

• The Inline Axis is the direction that text flows within a single line.
• The Block Axis is the direction in which new lines are stacked.

Let's see how this plays out:

• In standard English (writing-mode: horizontal-tb): The inline axis runs horizontally, and the block axis runs vertically.
• In traditional Japanese (writing-mode: vertical-rl): The inline axis runs vertically, and the block axis runs horizontally.

Because these axes can switch, properties like width and height become ambiguous. Is width the size along the horizontal axis or the inline axis? Logical properties solve this ambiguity. We now have start and end for each axis:

• block-start: The "top" in English, but the "right" in vertical Japanese.
• block-end: The "bottom" in English, but the "left" in vertical Japanese.
• inline-start: The "left" in English, but the "top" in vertical Japanese.
• inline-end: The "right" in English, but the "bottom" in vertical Japanese.

Mapping Physical to Logical Properties (Level 1)

Level 1 introduced a comprehensive set of mappings from physical to logical properties. Here are a few key examples:

• width → inline-size
• height → block-size
• min-width → min-inline-size
• max-height → max-block-size
• margin-left → margin-inline-start
• margin-right → margin-inline-end
• margin-top → margin-block-start
• margin-bottom → margin-block-end
• padding-left → padding-inline-start
• padding-top → padding-block-start
• border-right → border-inline-end
• border-bottom → border-block-end
• left / right (for positioning) → inset-inline-start / inset-inline-end
• top / bottom (for positioning) → inset-block-start / inset-block-end

Level 1 also gave us useful shorthands like margin-inline (for start and end) and padding-block (for start and end).

Welcome to Level 2: What's New and Why It Matters

While Level 1 was a monumental step forward, it left some noticeable gaps. Certain fundamental CSS properties like float, clear, and resize had no logical equivalents. Furthermore, properties like border-radius couldn't be controlled logically, forcing developers to fall back to physical properties for fine-grained styling. This meant you could build a layout 90% of the way with logical properties, but would still need physical overrides for different writing modes, partially defeating the purpose.

CSS Logical Properties Level 2 addresses these shortcomings directly. It's not about introducing a radical new system, but about completing the one started in Level 1. It achieves this in two primary ways:

1. Introducing new logical properties and values for older CSS features that were inherently physical (like float).
2. Adding logical property mappings for complex shorthands that were previously ignored (like border-radius).

With Level 2, the vision of a fully flow-relative styling system is nearly complete, allowing us to build complex, beautiful, and robust components that work everywhere, for everyone, without hacks or overrides.

Deep Dive: New Logical Values and Properties in Level 2

Let's explore the most impactful additions that Level 2 brings to our developer toolkit. These are the tools that fill the gaps and empower truly universal component design.

Float and Clear: The Logical Revolution

The float property has been a cornerstone of CSS layout for years, but its values, left and right, are the definition of physical direction. If you float an image to the left of a paragraph in English, it looks correct. But switch the document direction to right-to-left (RTL) for Arabic, and the image is now on the "wrong" side of the text block. It should be on the right, which is the start of the line.

Level 2 introduces two new, logical keywords for the float property:

• float: inline-start; This floats an element to the start of the inline direction. In LTR languages, this is the left. In RTL languages, it's the right. In a vertical-rl writing mode, it's the top.
• float: inline-end; This floats an element to the end of the inline direction. In LTR, this is the right. In RTL, it's the left. In vertical-rl, it's the bottom.

Similarly, the clear property, used to control the wrapping of content around floated elements, gets its logical counterparts:

• clear: inline-start; Clears floats on the inline-start side.
• clear: inline-end; Clears floats on the inline-end side.

This is a game-changer. You can now create classic image-with-text-wrap layouts that automatically adapt to any language direction without a single line of extra CSS.

Enhanced Control with Logical Resize

The resize property, commonly used on a textarea, allows users to resize an element. Its traditional values are horizontal, vertical, and both. But what does "horizontal" mean in a vertical writing mode? It still means resizing along the physical horizontal axis, which might not be what the user or designer intends. The user likely wants to resize the element along its inline axis to make lines longer or shorter.

Level 2 introduces logical values for resize:

• resize: inline; Allows resizing along the inline axis.
• resize: block; Allows resizing along the block axis.

Using resize: block; on a textarea in English allows the user to make it taller. Using it in a vertical writing mode allows the user to make it wider (which is the block direction). It just works.

`caption-side`: Logical Positioning for Table Captions

The caption-side property determines the placement of a table's caption. The old values were top and bottom. Again, these are physical. If a designer's intent is to place the caption "before" the table's content, top works for horizontal writing modes. But in a vertical-rl mode, the "start" of the block flow is on the right, not the top.

Level 2 provides the logical solution:

• caption-side: block-start; Places the caption at the start of the block flow.
• caption-side: block-end; Places the caption at the end of the block flow.

`text-align`: A Foundational Logical Value

While the values start and end for text-align have been around for a while, they are a core part of the logical properties philosophy and worth reinforcing. Using text-align: left; is a common mistake that immediately causes layout issues in RTL languages. The correct, modern approach is to always use:

• text-align: start; Aligns text to the start of the inline direction.
• text-align: end; Aligns text to the end of the inline direction.

The Crown Jewel of Level 2: Logical `border-radius`

Perhaps the most significant and powerful addition in Level 2 is the set of properties for controlling border radii logically. Previously, if you wanted a card to have rounded corners only at the "top", you would use border-top-left-radius and border-top-right-radius. This breaks down completely in a vertical writing mode, where the "top" corners are now the start-start and end-start corners.

Level 2 introduces four new longhand properties that map to the four corners of an element in a flow-relative way. The naming convention is border-[block-edge]-[inline-edge]-radius.

• border-start-start-radius: The corner where the block-start and inline-start sides meet.
• border-start-end-radius: The corner where the block-start and inline-end sides meet.
• border-end-start-radius: The corner where the block-end and inline-start sides meet.
• border-end-end-radius: The corner where the block-end and inline-end sides meet.

This can be tricky to visualize at first, so let's map it out for different writing modes:

Mapping `border-radius` in `writing-mode: horizontal-tb` (e.g., English)

• border-start-start-radius maps to top-left-radius.
• border-start-end-radius maps to top-right-radius.
• border-end-start-radius maps to bottom-left-radius.
• border-end-end-radius maps to bottom-right-radius.

Mapping `border-radius` in `writing-mode: horizontal-tb` with `dir="rtl"` (e.g., Arabic)

Here, the inline direction is flipped.

• border-start-start-radius maps to top-right-radius. (Block-start is top, inline-start is right).
• border-start-end-radius maps to top-left-radius.
• border-end-start-radius maps to bottom-right-radius.
• border-end-end-radius maps to bottom-left-radius.

Mapping `border-radius` in `writing-mode: vertical-rl` (e.g., Japanese)

Here, both axes are rotated.

• border-start-start-radius maps to top-right-radius. (Block-start is right, inline-start is top).
• border-start-end-radius maps to bottom-right-radius.
• border-end-start-radius maps to top-left-radius.
• border-end-end-radius maps to bottom-left-radius.

By using these new properties, you can define corner radiuses that are semantically tied to the flow of content, not the physical screen. A "start-start" corner will always be the correct corner, regardless of language or text direction.

Practical Implementation: Building a Global-Ready Component

Theory is great, but let's see how this works in practice. We'll build a simple profile card component, first using the old physical properties, and then refactor it to use modern logical properties from both Level 1 and Level 2.

The card will have an image floated to one side, a title, some text, and a decorative border and rounded corners.

The "Old" Way: A Brittle, Physical-Property Card

Here's how we might have styled this card a few years ago:

/* --- CSS (Physical Properties) --- */

.physical-card {

  width: 300px;

  padding: 20px;

  margin-bottom: 20px;

  border: 1px solid #ccc;

  border-left: 5px solid steelblue;

  border-top-left-radius: 8px;

  border-bottom-left-radius: 8px;

}

.physical-card .avatar {

  float: left;

  width: 80px;

  height: 80px;

  margin-right: 15px;

}

.physical-card h3 {

  margin-top: 0;

  text-align: left;

}

In a standard English LTR context, this looks fine. But if we place this inside a container with dir="rtl" or writing-mode: vertical-rl, the layout breaks. The decorative border is on the wrong side, the avatar is on the wrong side, the margin is incorrect, and the rounded corners are misplaced.

The "New" Way: A Robust, Logical-Property Card

Now, let's refactor the same component using logical properties. We'll leverage properties from both Level 1 and the new additions from Level 2.

/* --- CSS (Logical Properties) --- */

.logical-card {

  inline-size: 300px;

  padding: 20px; /* `padding` shorthand is already logical! */

  margin-block-end: 20px;

  border: 1px solid #ccc;

  border-inline-start: 5px solid darkcyan;

  border-start-start-radius: 8px; /* Level 2 Power! */

  border-end-start-radius: 8px; /* Level 2 Power! */

}

.logical-card .avatar {

  float: inline-start; /* Level 2 Power! */

  inline-size: 80px;

  block-size: 80px;

  margin-inline-end: 15px;

}

.logical-card h3 {

  margin-block-start: 0;

  text-align: start;

}

Testing and Verification

With this new CSS, you can drop the component into any container, and it will automatically adapt.

• In an LTR context: It will look identical to the original physical version.
• In an RTL context (dir="rtl"): The avatar will float to the right, its margin will be on the left, the decorative border will be on the right, and the text will be start-aligned (to the right). The rounded corners will correctly be on the top-right and bottom-right. It just works.
• In a vertical context (writing-mode: vertical-rl): The card's "width" (now its vertical inline-size) will be 300px. The avatar will float to the "top" (inline-start) with a margin on its "bottom" (inline-end). The decorative border will be on the right side (inline-start), and the rounded corners will be on the top-right and top-left. The component has completely re-oriented itself correctly without any media queries or overrides.

Browser Support and Fallbacks

This all sounds fantastic, but what about browser support? The good news is that support for Level 1 logical properties is excellent across all modern browsers. You can and should be using properties like margin-inline-start and padding-block today.

Support for the newer Level 2 features is rapidly improving but is not yet universal. The logical values for float, clear, and resize are well-supported. The logical border-radius properties are the newest and might still be behind feature flags or in recent browser versions. As always, you should consult resources like MDN Web Docs or CanIUse.com for the most up-to-date compatibility data.

Strategies for Progressive Enhancement

Since CSS is designed to be resilient, we can easily provide fallbacks for older browsers. The cascade will ensure that if a browser doesn't understand a logical property, it will simply ignore it and use the physical property defined before it.

Here's how you can write fallback-ready CSS:

.card {

  /* Fallback for older browsers */

  border-left: 5px solid darkcyan;

  border-top-left-radius: 8px;

  /* Modern logical property that will override the fallback */

  border-inline-start: 5px solid darkcyan;

  border-start-start-radius: 8px;

}

This approach ensures a solid baseline experience for everyone while providing the enhanced, adaptive layout for users on modern browsers. For projects that don't need to support multiple writing modes, this might be overkill. But for any global application, design system, or theme, this is a robust and future-proof strategy.

The Future is Logical: Beyond Level 2

The transition from a physical to a logical mindset is one of the most important shifts in modern CSS. It aligns our styling language with the reality of a diverse, global web. It moves us away from brittle, screen-oriented hacks toward resilient, content-oriented design.

Are there still gaps? A few. Logical values for properties like background-position or gradients are still being discussed. But with the release of Level 2, the vast majority of day-to-day layout and styling tasks can now be accomplished using a purely logical approach.

The call to action for developers is clear: start defaulting to logical properties. Make inline-size your go-to instead of width. Use margin-inline instead of setting left and right margins separately. This isn't just about supporting different languages; it's about writing better, more resilient CSS. A component built with logical properties is inherently more reusable and adaptable, whether it's used in an LTR, RTL, or vertical layout. It's simply better engineering.

Conclusion: Embrace the Flow

CSS Logical Properties Level 2 is not just a collection of new features; it's the completion of a vision. It provides the final, crucial pieces needed to build layouts that respect the natural flow of their content, whatever that flow might be. By embracing properties like float: inline-start and border-start-start-radius, we elevate our craft from simply positioning boxes on a screen to designing truly global, inclusive, and future-proof web experiences.

The next time you start a new project or build a new component, pause before you type margin-left. Ask yourself, "Do I mean the left, or do I mean the start?" By making that small mental shift, you'll be contributing to a more adaptable and accessible web for everyone, everywhere.